Subject: Comments on IBM's Response to Public DataNet Routing Concerns

From: "jim (j.) cobban" <[email-masked]>
Date: Thu, 22 Jun 1995 11:56:00 -0400

In this continuation of the discussion of the interaction of the APPN
routing algorithm and subnetworks which provide varying classes of service,
I wish to expand on my concerns.

Let us take a simple case of two APPN nodes which are connected by a
subnetwork which provides a distinction between low and high priority.  We
establish two virtual circuits between those nodes, one at each priority.
It is the desire of the customer that their high priority traffic, for
example CPSVCMGR and #INTER, should use the high priority TG, and their low
priority traffic, for example #BATCH, should use the low priority TG.  In
each case this use should be exclusive, except if one or the other of the
two TGs is unavailable.

In order to achieve this exclusivity, with backup in the event of a single
failure, each COS tab entry must be defined with pairs of rows.  The first
of each pair of rows specifies a range of TG characteristics which, in at
least one column, is mutually exclusive of the values in the corresponding
rows in COS entries with a different desired subnetwork priority.  The
reason that the default COS tables cannot be used to select TGs by
subnetwork priority is that there are no rows which have mutually exclusive
values.

Now the actual measured effective capacities, network delays, security, byte
cost, and time cost of these two TGs will be almost identical, because they
are using exactly the same facilities.  They differ only in the interaction
of the two classes of service, and then generally only in high stress
situations, not normal operation.  In order to avoid distorting the behavior
of the route selection algorithm in the portion of the APPN network which is
not going through the switched subnetwork, it is highly desireable that all
of these standard attributes reflect as closely as possible the real
behavior of the TG.  If we adjust the COS tables so that they have at least
one row which is mutually exclusive on some of these existing columns, there
is again a high risk of distorted behavior in the conventional portion of
the network.

Based upon these considerations I have concluded that it is necessary to use
an additional column to create the mutually exclusive rows.  In the absence
of an architectural change, I have used User Parm 3.  Each existing row of
the COS entry is duplicated in all existing parameters except User Parm 3.
Each new row is inserted in front of the original row, with a range of User
Parm 3 which corresponds to the desired subnetwork priority, and a weight
which is slightly less than the weight of the existing row.

In the simple example here, let's say that low priority TGs have a U3 value
of 0x40 and high priority TGs have a U3 value of 0xC0.  Each new row of a
COS entry which prefers low priority TGs will have a U3 range of 0 to 0x7F.
Each new row of a COS entry which prefers high priority TGs will have a U3
range of 0x80 to 0xFF.  These are completely arbitrary values just to
demonstrate what I mean by mutually exclusive rows, and how they could
interact with TGs with different subnetwork classes of service.

Now this does seem to satisfy the customer requirement.  If both VCs, that
is TGs as seen by APPN, are working then sessions requesting a COS
associated with high priority will cause a TG associated with a high
priority VC to be selected, if that is the best route through the network.
Similarly sessions requesting a low priority COS will select a TG associated
with a low priority VC, if that is the best route.

The cost is the addition of at least one row to each COS entry.  There are
some problems with that. 

  1) A number of implementations have imposed a limitation of 8 TG rows per
     COS entry.  That means that if we add this new row, we must sacrifice
     some other row.  I cannot find any architectural statement that there
     is a limit on the number of rows, but 8 is certainly the limit in the
     implementations I have checked.
  2) The customer may already be using all of the User Parms for some other
     purpose.  In this case there are no available characteristics which can
     be used to create the mutual exclusivity between the two TGs.

Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcars153!jcobban       |  FAX:   (613) 763-5199
|                                                                             |
|   The opinions expressed are those of the author and do not necessarily     |
|   represent the opinions of Bell-Northern Research or Northern Telecom.     |

---

From: [email-masked] (Dave Finnie)
Date: Fri, 23 Jun 95 09:19:19 EST

Jim,

I think you've raised some excellent points.

My personal view is that route selection according to
subnetwork priority is something that should be addressed by
the APPN architecture. I don't believe it is something that
should be left up to customers (via user fields in COS) for 
the following reasons:

 * There is a good chance that they will get it wrong (possibly
   because they don't understand it fully). The net result is
   that they will see the poor route selection as an architecture
   or implementation deficiency.

 * Some may see this custom modification of COS tables as a
   task that makes APPN less desirable.

 * As you pointed out - they are user fields, and may already
   be in use.

I also agree that manipulation of TG characteristics can cause
problems (for mostly the same reasons).

An additional column (and rows) to COS tables sounds like it could
work, but I can see the following problems:

 * All NNs serving OLUs and those connected to multi-priority
   subnetworks would require new releases to support the new
   column. In addition, their COS tables would require updating.

 * As I understand it, support for ATM QOS poses problems which
   encompass this one. Therefore, we don't want to go ahead and
   enhance the architecture for this problem, only to realise
   that we have only half solved the real issues.

To the architecture group: Do you have a feel for how to approach
the ATM QOS problem ? Would it co-exist with Jim's suggestion ?

Dave